微服務瞎談

微服務這幾年超級夯!!!
工作中有些筆記跟服務使用上的經驗做些分享. 也藉此複習。
基本上不會特別分享要怎做, 但會從幾個唯度來分析.
還有分享幾個微服務的設計原則以及分散式系統的幾項必須考慮的原理.

微服務架構興起的原因

為了解決單體架構的一些不足.

單體架構(Monolithic)下，各業務系統之間是緊密耦合的，各個模組都是運行在同一個程序裡,
每次上版就要重啟整個程序。
也因此，在模組數量增長時，造成服務啟動變久，佈署時間拉長，更提升風險。
所以很多公司選擇安排一段時間停止服務進行維護做上版佈署。
又因為雞蛋放在同一個籃子裡，一個項目出錯，整個網站就面臨無法提供服務的狀態(就像下圖Something went wrong、Oops，500)

雖然程序可以佈署多份，並透過反向代理(Reverse proxy)，或負載均衡做動態調整。但這種架構下，不同業務訪問同一份資料庫，有些資源可能佔用大量資料庫CPU time或記憶體，此時，進行模組擴充會有相當大的困難度。

Pattern: Monolithic Architecture

所以就慢慢的出現一些架構，SOA、RPC、分散式架構，直到這裡說的微服務架構。

"微服務"架構

Pattern: Microservice Architecture

先講解什麼是微服務。

微服務

微服務(Microserivce)，為什麼不叫Mini-service?
微服務宗旨就是一個"K.I.S.S"原則- Keep It Simple And Stupid; 白話來說就是一個程序只做一件事情，微服務來說就是聚焦在一個業務上。

以此衍生出幾個"微"服務的設計原則(Design Principle)

1. 高內聚， 低耦合
2. 高度自治
3. 圍繞在業務能力進行規劃
4. 彈性設計
5. 日誌與監控
6. 全面自動化
   
   這圖包含了實現微服務時要考慮的點, 這裡我沒全部列舉, 只是講幾個我認為重要的.

高內聚， 低耦合

每個服務針對一個單一職責(SRP)的業務能力做封裝。 (這太抽象了)
這件事情的定義非常的模糊，因此更多時候，會需要Domain Expert(領域專家)，從業務上的角度做職責切分，或根據Subdomain做劃分。
自然會達成高內聚(因為都在只面對同一類的業務)。

低耦合，因為服務之間彼此不在同一個程序裡，僅透過一些通訊協定與接口做溝通，使得程序之間相對獨立，服務自然就處於低耦合的狀態了。
同時消除了隱式的數據依賴，僅存在服務之間彼此溝通傳遞資料。

高度自治

1. 服務能獨立佈署和擴展，每個服務都各自運行在獨立的程序內，這賦予了靈活的佈署方式，使得快速迭代交付有可能實現。
2. 獨立開發與各自系統演化，技術選型靈活化，不再受到技術債的迫害。
   可依業務自己選擇適合的技術來開發，獨立演化. 服務之間僅透過網路協議與接口相互溝通。
3. 獨立的團隊與自治，團隊就能對服務的整個生命週期負責，僅需關心負責的邊界上下文(Bounded Contexts)

圍繞在業務能力進行規劃

每個服務代表特定業務邏輯，而明顯定義的Bounded Contexts. 就能快速圍繞在業務進而組織團隊。 而明顯的Bounded Contexts可以隔離實做上的細節(ISP)，就能抽象出業務邏輯，建立業務模型，使模型能重複被使用。

彈性設計

容錯，服務降等，限流，熔斷器，服務限流，防止雪崩等等的機制。

ref:
服務自適應熔斷原理與實現

目標是作到服務可以滿足以下特性:
Availability(可用性)、Reliability(可靠性)、Controllability(可控制性)、Observability(可觀察性)。

日誌與監控

為了達成Observability(可觀察性)，方便對產線環境進行快速的問題定位，檢測出可能發生的異常或是故障。
監控包含可用狀態，請求流量，錯誤計數，鍊路調用追蹤等等的。
以結構化的日誌與界面做展示.。

全面自動化

因為不再像傳統的單體架構就少量的程序需要佈署，要是依賴手動部署，很可能出錯且部署很慢。
所以會需要一些非手動的方式來提昇效率和降低成本。
利用自動化的運維服務來協助。

遺留的系統與服務怎辦? 能否慢慢轉成微服務?

扼制模式Strangler application

重作???
賣鬧阿，風險太大，老闆也不想看到資源拿去重作，且前人的智慧，一時半刻間是無法領悟的。
應該像上圖，這樣逐步重構，時間久了，單體程序所涵蓋的功能與業務會越來越少。
很多人都想"一步到位"，但是在到位之前，是沒任何好處與價值的。
快速能交付，才是我們希望的。

因此有幾種策略:

1. 新的功能與業務，乾脆將之以服務的方式來開發(避免繼續疊床架屋)
2. 透過interface或抽象，隔離表達層與實做層
3. 把單體內的功能模組，提取到新的服務中，強行拆解單體

Strangler pattern Ref.

Anti-corruption layer

Anti-corruption layer防腐層，又稱為膠水代碼(Glue Code)。
用來保護全新定義出來的領域模型，不受到單體模型的污染; 替這兩個模型之間進行翻譯轉換。
使得新的服務，能夠透過Glue code去調用單體服務的所有資料與功能。

Glue code在設計模型內能透過Adapter Pattern+Facade來實做.

DDD社團

幹話王部落格

OpenTelemetry 入門指南：建立全面可觀測性架構